Date: Thu, 27 Jan 94 04:30:01 PST From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #24 To: tcp-group-digest TCP-Group Digest Thu, 27 Jan 94 Volume 94 : Issue 24 Today's Topics: Ethernet protocol ID TCP MSS and TCP WIN settings (2 msgs) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Wed, 26 Jan 94 10:44:14 PST From: efb@suned1.Nswses.Navy.Mil (Everett F Batey) Subject: Ethernet protocol ID To: tcp-group@ucsd.edu Last time I looked there was a complete list of known Vers 2 typefields in ftp.ftp.com or some such anan ftp server at ftp .. .. Might do good to post it here from time to time .. Also .. If anyone has done any Public Domain work like Sun_s snoop .. similar in function to Ether Sniff (c?) from Data General or whoevers ether ent tester I would appreciate a lead to that if it runs on a dos box and runs with winsock. Welcome and Thanks /Ev .. Wa6Cre/ > > Does anyone know where I can find a concise (or as consise as possible) > listing of known ethernet protocol id's?? I know in the ethernetdump > routing in NOS it identifies 3 of them and then just displays the p **** FTP Software has this fantastic poster that splits ethernet packets up into protocol layers and lists all or many of the fields in each layer. They usually give it out at trade shows, and if you called them and asked nicely, they just might send you one. ------------------------------ Date: Wed, 26 Jan 1994 10:44:07 -0800 From: Phil Karn Subject: TCP MSS and TCP WIN settings To: iiitac@pyramid.swansea.ac.uk The MTU Discovery feature allows you to periodically "probe" the path with a larger packet to see if the minimum MTU has increased since you last stopped getting ICMP messages. Of course, it is somewhat problematical to choose the interval at which you do this probing, because each packet that bounces wastes bandwidth on the links up to the bounce point. Phil ------------------------------ Date: Wed, 26 Jan 1994 15:52:58 -0500 From: goldstein@carafe.tay2.dec.com Subject: TCP MSS and TCP WIN settings To: tcp-group@ucsd.edu Phil, It's hard to determine the real motivations behind a political situation, but it might be surmountable. I don't see the exact problems you see though; things might not be as bad as they look: >I think there are three problems: one, there was a widespread perception >that there must exist a way to control gateway congestion without >having to modify IP and every router that handles it. True. You would have to modify all the IPs to at least pass the bit, if they don't pass it now. One rule of DECbit is that a router need not implement it, but must never clear it. >Two, the >NSFNet backbone bandwidth has increased almost 1,000x over what it was back when TCP congestion control algorithms were such a hot topic. >Despite the enormous growth of the net this has pretty much eliminated >the widespread backbone congestion that used to occur back then, so >there is now much less interest in this problem. Raj describes that as a classical fallacy, albeit one with much political clout. You can't solve congestion with bandwidth, just move it. Now the backbone is fat but congestion occurs at the low- bandwidth egress points ("on-ramps"). ATM nets will really see this. >Three, both TCPs >in a connection have to be aware of the scheme, because the sending >TCP relies on the other TCP to "reflect back" the IP congestion >experienced bit in its own header. It's simpler than that. The congestion window is in the receiver, not the sender. All you need to do is lower the advertised window size, not echo back the bit. That's an advantage of TCP over, say, HDLC, whose only window is in the sender. The way we do it is to make the advertised window the lesser of buffer-space (normal window) or congestion-allowed window size. The _loss_ (VJ/CUTE) window in DECnet/OSI lives in the transmitter, but the _congestion avoidance_ window is the receiver's. Thus if only one end does it, it can slow down the ignorant TCP doing the sending. >I still think it's not too late to install the Decbit scheme in IP. >There's a spare bit in the flags field (right next to the MF and DF >bits) that could be used. I've had code in my own IP and TCP for some >time that reflects this bit back in another spare bit in the TCP >header, in preparation for eventually implementing the scheme. Again, >I wanted to make sure that there would be enough compatible systems >out there to make this thing work. But I haven't taken it beyond that. That spare bit just sort of begs to be used for this, doesn't it? I think somebody once suggested it at IETF but got nowhere, but then I only know that as hearsay and I don't even remember from whom. fred k1io ------------------------------ End of TCP-Group Digest V94 #24 ******************************